2020年的 Q4 期間，我對幾場面試的印象非常深刻，連續三位來自不同公司，不同領域背景的應徵者，不約而同在面試中提到：

「我目前的團隊在跑 Scrum ，但總感覺很不對勁，尤其估點很花時間…」

「我們參考網路常提到的費式數列卡牌估點法，每個工程師都可以投點，但不同領域的人一起估，根本沒有參考價值…」

「我的團隊之前都有估點，到估出來的點數作用是什麼，其實我們也一知半解，最後 PO 就說不估了，能做多少算多少…」

這樣的情況在業界肯定不少見，我經歷的幾個團隊，也曾為此困擾不已。本文不會針對 Google 上查找得到的估點方式做詳細介紹，而是透過個人觀點來探討為何許多團隊在這些估點制度上會深陷泥沼。在下半部文章，我會介紹一個由我永遠懷念的新創團隊 (Soccii) 所共創出來的一種估點系統。

本文資訊，對許多 Scrum 專家來說，可能是異端邪說，服用注意，也歡迎留言討論。

以下我們先探討常見的估點方式兩道難題：

難題 1：平均攻速

Fibonacci 數列估點法的點數，其實代表對 User Story 的複雜度評估，在估點的當下，不與開發時間掛勾。團隊的「平均攻速」，可以用來評估產品功能的所需開發時間，我們可以透過以下的算式計算：

這裡的執行難處有兩個：

• 總工時 ( Hours ) 的統計對工程師來說相當瑣碎，如開發過程中的暫時中斷、思考時間、設計時間等計算原則；另外，工程師要養成一個新的工作習慣，會大量消秏精神。進而形成張力-舒緩系統。
• 為減少偏差，必須取得多個 Sprint 的統計結果進行平均，這個過程可能橫跨數月，統計難度高。實務經驗中，分秒必爭的新創團隊，或是交付型團隊，較難承受這樣的時間維度，因此仍高度仰賴 PO 的經驗與領導力。

難題 2 ：異質開發團隊

目前常見的產品團隊，可能由多個不同領域的工程師組合而成：

• 後端工程師
• 行動開發工程師 ( Android / iOS )
• 前端工程師
• C++
• QA

一個較具規模的開發團隊人數可能高達超過 20 人，違背 Scrum Guide，卻真實存在於企業現場。我們想像一下，如果採用費式卡牌估點法，在極端的情況下，由 20 個人同時對 User Story 進行投點的情境，肯定是混亂，且秏時。最終帶來的變形，是僅參考領域專家的觀點，而其他人的投點，只是在陪榜。

上述的兩個難題，常見的張力-舒緩系統如下：

因此，團隊會在估點活動上遇到困難，是一種結構性問題，這種結構會自然的帶團隊到放棄的結論。各種微調，都無法與系統張力對抗。沒錯，我們需要的是一個新的估點系統。

我的經驗並非否定業界有團隊可以把諸如「費式卡牌」、「T-shirt 大小估點法」執行的非常好；我就曾經聽過一位經驗豐富的工程主管兼任 Scrum Master 分享過他的成功經驗。我的重點在強調「落地」的重要性。身為工程主管，完成商業價值是我的責任；而讓團隊系統在實踐 Scrum 的各項精神時，能有最小的阻力，是身兼 Scrum Master 的責任。沒有最好，只有選擇。

明天的下篇，就來正式介紹變形的估點系統。